今天是那種「腦袋比 CPU 還忙」的一天。
系統雖然已經能監控自己、報警自己,但我覺得它還能更聰明一點。
所以今天的主軸是兩件事:監控升級與測試覆蓋率救援計畫。
過去的監控只會報「API 正常 / 錯誤」。
今天我讓它開始懂得問:「我最近是不是慢了?」
透過這波更新,我加入了完整的 業務監控與效能監測系統:
/api/v1/monitoring/health
/api/v1/monitoring/performance
/api/v1/monitoring/business
/api/v1/monitoring/alerts
/api/v1/monitoring/dashboard
系統現在不只會報錯,還會說:「我今天表現不錯 👍」。
這才是 AI 世代的監控該有的氣質。
剛重建完鏡像,容器卻冷不防給我一句:
dial tcp [::1]:5432: connect: connection refused
😅
原來新容器用了錯的環境變數(拆分成 HOST + PORT),
但應用程式期望的是 DATABASE_URL
。
修復後改回這樣:
DATABASE_URL=postgresql://teamsnotify:teamsnotify123@teamsnotify-postgres:5432/notification_center?sslmode=disable
REDIS_URL=redis://teamsnotify-redis:6379
重新啟動後一切恢復正常,
監控指標出現了新的 JSON:
{
"notifications_sent": 5,
"notifications_failed": 1,
"success_rate": 83.33,
"teams_api_calls": 6
}
那一刻真的有種「活了」的感覺 🧬。
我讓指標不只是展示數字,而是從程式碼自己更新。
在 notificationService.SendNotification()
中,
每發一封通知就會更新 Redis 的統計:
IncrementNotificationSent()
IncrementNotificationFailed()
IncrementTeamsAPICall()
同時我還改寫了日誌輸出格式:
現在 log 檔看起來像是財報,一目了然又有美感 📈。
在完成監控系統後,我跑了個覆蓋率報告——結果心臟差點停機 💀
整體覆蓋率只有 1.2%。
我立刻啟動「拯救覆蓋率計畫」。
階段 | 覆蓋率 | 提升幅度 | 狀態 |
---|---|---|---|
初始 | 1.2% | - | ❌ |
高優先級測試 | 3.0% | +150% | ✅ |
中優先級測試 | 6.7% | +123% | ✅ |
改進後 | 7.3% | +9% | ⚙️ 進行中 |
我新增了以下測試:
現在的覆蓋率雖然還不到 10%,
但測試分層架構、Mock 機制、Redis 整合都已成形。
我仔細分析後發現主要有四點:
目標:
短期 → 15%
中期 → 30%
長期 → 60%
一步步推上去,直到每一行代碼都被信任。
監控系統完成後,我連文檔也同步更新:
文件 | 進度 |
---|---|
MonitoringGuide.md | ✅ 100% |
UserManual.md | ✅ 95% |
Architecture.md | ✅ 90% |
DocumentationSyncGuide.md | ✅ 新增完成 |
同步率從 80% 提升到 95%,
我甚至寫了一支小工具 check-doc-sync.sh
幫忙檢查版本。
這下文檔不再是「寫過就忘」的東西,而是開發流程的一環。
類別 | 成果 |
---|---|
📊 系統監控 | 業務指標與效能監控全面實現 |
🧱 部署穩定化 | 容器修正 + 網路連線成功 |
🧩 日誌 | 結構化輸出 + BusinessMetricsLogger |
🧪 測試 | 覆蓋率提升至 7.3%,測試架構完善 |
📘 文檔 | 同步率達 95%,新增檢查腳本 |
今天的主題其實就一句話:
「沒有監控的系統,等於閉著眼睛開車。」
現在,我的系統會說話、會報警、會監控自己、還會記錄表現。
覆蓋率雖然還不高,但基礎已經穩得像鋼筋混凝土。
明天目標?
讓這座系統不只是「會監控」,
而是「會預測」。🔮